Computer systems typically utilize a layered approach for implementing functionalities relating to communications frameworks where a protocol layer is a program module for processing different portions of data traveling from a network to an application or when the application decides to send data out to remote peer over the network. The layered approach requires examination of data by each protocol layer to determine if any work needs to be performed by that layer before sending the data to the next protocol layer.
In some conventional implementations “horizontal perimeters” are provided to provide per module or per protocol stack layer processing. This leads to the same packets being processed on more than one Central Processing Unit (CPU) in a multi-CPU environment. In addition, conventional techniques typically provide only a single application in multi-CPU environments. This means that applications and packets can be processed by different CPU's at various times. In addition, data related to the applications (application data) is shared between the CPU's.
In any case, conventionally, in a multi-CPU environment (e.g., multi-processor server) data (message packets) can be stored and processed by different CPU's at various layers in the process. Typically, for better efficiency, the application data is stored in caches associated with the CPU that is currently processing the message packets. But if the processing CPU changes at any time, a cache miss can occur. This means that, among other things, message packets may need be transferred from the cache of one CPU to the cache of another CPU. This means that any one of the CPU's can be interrupted when data (e.g., a packet) is received into the shared operating system via a network interface. The CPU that is interrupted needs to access data. However, data may be in cached in another CPU (i.e., not the interrupted CPU). This results in the need for cache miss handling. Moreover, if the cache was modified in between, this operation becomes very expensive. This problem is exacerbated in environments where there is a significant data load on the system (i.e., the system is very busy).
One approach to combating this problem was to introduce vertical perimeter architectures. Such vertical perimeters vertically integrate message processing in a manner that specifically binds a designated network interface card to a specific CPU for all message traffic through the designated network interface card. This is accomplished using an S-queue (serialization queue) that enables the vertical processing of a message by the same CPU at all steps required to process a message of the designated network interface card. Moreover, such architectures are capable of controlling the interrupt mode used to pass messages between the network interface card and the kernel of the operating system. Thus, when the S-queue becomes too full or when the rate at which data is been received by the NIC becomes higher than some threshold the interrupt mode is of the network interface is halted until the is more room in the associated S-queue. The nature of some vertical perimeter architectures is explained in greater detail in, for example, U.S. patent application Ser. No. 10/767,021, entitled “VERTICLE PERIMETER FRAMEWORK FOR PROVIDING APPLICATION SERVICES”, filed on Jan. 28, 2004, which has been incorporated by reference.
Such conventional vertical perimeter frameworks are suitable for many purposes, but when the number of network interfaces exceeds the number of CPU's certain system inefficiencies slow reduce the capacity of the overall systems. For example, if the data from two NIC's are being input into the same S-queue the system cannot readily distinguish which NIC provided the data. Any efforts to distinguish which NIC provided a given piece of data would require a further investment of kernel processing time thereby further slowing down the operation of the system. Thus, if one NIC (e.g., NIC A) is pouring in a large amount of data and another NIC (e.g., NIC B) is pouring in a relatively small amount of data the slower NIC (NIC B) suffers. This is due to the serial nature of the S-queue. Data comes out in the order it was placed in the S-queue. This results in significant kernel time being devoted to the processing of messages for NIC A and less time for NIC B. Thus, a connection using NIC B can have a very long delay before a connection can be completed due to large number of messages for NIC A that must be processed first. Moreover, NIC B is doubly penalized because every time a new piece of data comes in for NIC A the kernel is interrupted further slowing processing. Also, if an extraordinarily large amount of data arrives from NIC A, the S-queue can be completely filled require NIC B data to remain on the NIC until such time as there is room in the S-queue. Also, because two (or more) NIC are now feed data to the S-queue the system loses its ability to regulate the data flow from the NIC. Therefore, improvements can be made.